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1.0  Introduction 


The  idea  that  data  models  can  be  equivalent  to  one  another  and  the 
belief  that  the  cost  of  (expensive)  conversion  between  database  management 
systems  can  be  achieved  automatically  are  not  new.  Indeed  the  concept  of 
the  universal  language  and  of  ease  of  translation  across  languages  arose 
early  in  modern  computing  history.  However,  one  of  the  most  elusive  parts 
is  in  finding  a  model  that  allows  such  translation-  for  it  must  be  general 
enough  to  cover  all  such  systems. 

In  searching  for  methods  of  data  representation,  data  semantics, 
and  consequently  methods  of  translation,  the  authors  started  to  work  on  a 
data  model  processor  that  could  provide  a  framework  for  testing  data  models 
as  well  as  allow  development  of  a  data  model  theory.  This  report  provides 
a  short  history  of  the  project,  as  well  as  stating  some  of  the  most  recent 
concepts,  and  finally  makes  some  suggestions  for  future  development. 


2.0  Data  Model  Definitions  and  Concepts 

During  the  past  five  years,  there  has  been  a  coordinated  data 
model  study  group  in  the  Department  of  Information  Systems  Management  at 
the  University  of  Maryland.  The  work  of  this  group  commenced  when  Hardgrave 
worked  with  Childs  (ref.  1)  in  understanding  the  theory  and  applicability 
of  Extended  Set  Theory.  This  led  Hardgrave  to  startinq  an  implementation 
of  the  concept  using  integer  sets  (ref.  2)  and  then  in  expanding  this  into 
positional  set  notation  (ref.  3)  for  defining  data  models.  The  work  re¬ 
quired  both  the  introduction  of  new  implementation  methods  as  well  as  some 
theoretical  considerations. 

During  several  working  sessions  in  1975,  Rothnie  and  Sibley  worked 
with  Hardgrave  in  considering  the  concepts  of  data,  data  models,  and  the 
needs  of  large  scale  distributed  database  systems.  This  led  to  several  new 
ideas  expressed  in  reference  4,  and  this  formed  a  basis  for  further  work, 
some  of  which  is  reported  here. 

One  of  the  major  difficulties  with  writing  about  data  models  and 
their  theory  is  the  need  for  a  concise  definition  and  understanding  on  the 
part  of  the  reader.  The  jargon  of  data  management  is  notoriously  poorly 
defined,  with  many  words  being  used  for  the  same  (or  similar)  concepts  and 
many  concepts  being  called  by  the  same  word.  In  fact,  one  of  our  goals  has 
been  to  provide  a  notation  and  framework  that  encourages  precise  mathemat¬ 
ical  definition  of  data  modelling  concepts.  Unfortunately,  such  discussion 
is  extremely  difficult  (if  not  impossible)  to  condense.  This  has  led  to 
several  extremely  long  papers  (ref.  5,  6,  7,  and  8),  and  even  these  have 
not  been  independent. 

Our  recent  work  has  taken  three  important  steps: 

1)  The  implementation,  simulation,  and  improvement  of  a  real 
positional  set  processor-PSP  (ref.  7). 
ii)  The  theoretical  framework  of  data  models,  and  the  provision  of 
an  augmented  PSP  that  can  test  and  support  several  data  models 
(ref.  8). 

iii)  The  beginnings  of  work  in  the  use  of  data  model  theory  for  the 
development  of  a  better  understanding  of  underlying  concepts 
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that  must  be  understood  for  future  standardization  of  DBMS. 
Some  extracts  from  previous  reports  are  now  included  for  completeness. 


2.1  The  Basic  Concepts  of  the  Positional  Set  Processor 

The  notion  of  the  positional  set  is  the  basic  concept  of  the  model 
under  consideration.  We  shall  briefly  review  the  material  of  as  follows. 
The  construction  o  d  o 

S  ■  [  X,P‘,  x/2,  ...  ] 

is  a  positional -set.  The  pairs  may  be  called  duplexes.  We  call  P_,  the  po¬ 
sit  i onaT-TdentTTTer  (position).  The  positional  identifier  may  be  "null" 
(denoted  by  #). 


The  component  X^  we  call  the  value  of  the  element  (or  simply  the 
element.  The  element  can  be  atomic  or^he  element  value  can  be  a  positional 
set;  thus  allowing  a  form  of  recursiveness. 

The  value  of  Xj  can  be  single-va luea  if 

vi,j  C  if  j  -  Pif  Pj] 

or  multi-valued  if 

h,j  t  if  J  -  Pi  s  pj] 

that  is,  there  exist  several  duplexes  with  the  same  positional  identifiers. 


If 

Vi  C  Pi  -  #  ] 

then  the  positional  set 

[  XlP',  X2Pj,  ...  XnP"  ] 
is  equivalent  to  the  classical  set 

{  X,.  X2,  Xs,  ...  X„  }. 

The  set 

[  Xi\  X22,  ...  Xnn  ] 
is  a  classical  sequence. 


Further,  we  shall  use  primitive  sets,  which  are  classical  sets  of 
scalar  values  with  different  characteristics.  The  specific  allowable  con¬ 
structs  or  sets  of  values  are  defined  by  the  DBMS  designer  and  are  fixed  in 
the  data  language  associated  with  the  model  under  consideration.  In  parti¬ 
cular,  we  shall  normally  need  to  use  primitive  integer  sets  and  real  sets, 
character-strings  of  fixed  and  variable  length,  etc. 

Some  subset  of  the  primitive  sets  we  shall  call  the  domain  which 
represents  the  possible  set  of  values  (v).  This  primitive  set  defines  the 
possible  elementary  values  which  are  associated  with  one  or  more  positional 
identifiers;  several  positional  Identifiers  of  one  or  several  positional 
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sets  can  be  associated  with  one  domain  (e.g.,  the  domain  TOWN  may  have  PIDs 
'RECEIVED  FROM'  and  'SENT  TO').  The  domain  can  be  implicit  or  enumerated. 

An  implicit  domain  is  defined  by  giving  the  primitive  set  and  the  subsetting 
criteria  for  this  subset.  Typically,  a  PICTURE  specifies  the  domain.  Such 
criteria  may  be  used  by  the  DBMS  as  a  domain  integrity-constraint.  For  an 
enumerated  domain,  elements  are  listed  explicitly.  This  list  of  values  may 
also  be  used  as  an  integrity-constraint. 

Turning  again  to  positional  sets,  we  can  see  that  data  objects 
associated  with  them  are  built  recursively.  We  define  the  depth  of  recursion 
of  the  atomic  element  to  be  zero.  Then  a  positional  set  has  recursion  deptli 
k  if  the  maximum  depth  of  recursion  of  its  elements  is  k-1. 

The  instance  of  a  positional  set  or  tunle  is,  by  definition,  a  po¬ 
sitional  set  which  conforms  to  the  definitional  constraints.  The  set  of  all 
instances  of  positional  sets  with  the  same  schematic  properties  we  may  call 
the  named  positional  set  (e.g.,  a  PERSONNEL  positional  set). 

Although  the  sequence  is  a  particular  case  of  a  positional  set, 
there  must  be  special  specifications  for  this  object,  because  it  plays  an 
important  role  in  the  model  under  consideration.  In  the  same  way  that  we 
distinguish  a  positional  set  according  to  its  name  and  instance,  we  shall 
distinguish  the  name  of  a  sequence  from  its  instance.  A  sequence  can  be 
of  fixed  or  variable  length. 

So,  the  positional  set  (sequence)  may  have  an  arbitrary  level  of 
recursion.  It  consists  of  duplexes.  A  duplex  consists  of  a  position  iden¬ 
tifier  and  an  element.  The  values  of  an  element  can  be  the  instances  of  a 
positional  set  of  some  type  (sequence)  or  they  may  be  atomic.  The  elemen¬ 
tary  value  in  this  duplex  can  be  single-valued  or  multi-valued.  The  con¬ 
ceptual  data-base  is  the  collection  of  positional  sets  with  given  character¬ 
istics. 


The  DBMS  which  uses  such  a  conceptual  model  must  have  domain  manip¬ 
ulation  facilities,  the  facilities  for  manipulating  named  positional  sets, 
their  instances,  duplexes,  single-valued  and  multi-valued  elements.  Before 
we  consider  the  data-manipulation  facilities  more  precisely,  we  shall  dis¬ 
cuss  the  functional  specifications  of  the  objects. 


2.2  Data  Model  Theory 

In  reference  4  the  authors  defined  a  data  model  to  be: 

•  A  collection  of  objects  (or  abstract  entities); 

•  A  data  definition  capability  for  those  objects- 
presumably  a  stored  structure  describing  objects;  and 

•  A  collection  of  operations  that  manipulate  the  objects 
by  referencing  names  in  the  data  definition  structure. 

In  reference  5  the  authors  refined  this  definition  somewhat  to  include 
specification  of  primitive  sets  from  which  other  positional  sets  could  be 
defined.  Our  approach  is  consistent  with  reference  4.  That  is,  a  data 
model  must  have  specified  as  a  minimum: 

l.  A  collection  of  primitive  sets. 
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2.  A  collection  of  objects  (i.e.,  abstract  entities). 

The  form  of  each  object  must  be  given  in  Positional- 
Set-Notation  (PSN) .  Further,  the  capability  for 
naming  an  object  must  be  specified  with  an  indication 
of  who  (e.g.,  the  end-user  or  the  DBA)  may  name  it. 

3.  A  stored  structure  representing  a  data  definition 
capability.  This  structure  must  also  be  given  in  PSN; 
it  may  be  as  complex  as  necessary. 

4.  A  collection  of  operations  that  manipulate  the  objects 
(usually)  by  referencing  the  data  definition. 

As  an  example,  we  have  given  a  data  model  definition  for  the  relational 
model  in  reference  6. 


3.0  Data  Model  Processor  Concepts 

The  development  of  a  Data  Model  Processor  will  be  a  significant 
step  towards  a  general  understanding  of  data  models.  This  research  involves 
several  important  parts;  first,  the  development  of  a  general  framework  for 
t  t  spv  if i  . t i oi ,  of  u.i ca  ii..  Je  1  sc .. ond t  ^ ,  1 1 spt  ^  tficution  of  eu ^ n  do . a 

model  (e.g.,  DB1G,  Relational,  1DMS,  IMS)  within  this  framework;  third,  the 
specification  of  query  languages  for  each  data  model.  Using  this  approach, 
several  query  languages  may  be  specified  for  a  given  data  model.  (The  re¬ 
lational  systems  may  be  considered  to  form  one  data  model  which  has  several 
query  languages,  such  as  SEQUEL  2,  QUEL,  and  QUERY-BY-EXAMPLE.)  In  the 
fourth  part  of  the  research,  it  is  necessary  to  define  a  method  which  allows 
specification  of  mappings.  Mappings  across  data-models  must  be  possible, 
as  well  as  mappings  within  one  data  mocfel .  Each  of  these  topics  is  now 
discussed  in  some  detail  to  show  how  far  the  research  has  currently  progres¬ 
sed. 


To  demonstrate  the  Data  Model  Processor  approach,  we  must  give  pre¬ 
cise  formulations  for  a  number  of  existing  data  models.  In  many  cases,  this 
means  augmenting  (and  sometimes  altering)  the  original  formulation.  For 
example,  the  original  relational  model  does  not  provide  a  mechanism  for  de¬ 
fining  domains.  Our  mathematical  approaches  are  not  intended  to  be  final; 
but  they  are  necessary  to  illustrate  this  approach. 


3.1  The  Data  Model  Processor  (DMP) 

We  see  the  framework  as  an  on-line  interactive  system  that  pro¬ 
vides  several  options  which  are  designed  to  support  the  study  of  data  models. 
The  user  of  the  DMP  system  would  first  encounter  a  "master  menu"  shown  in 
Figure  3-1. 

Each  option  is  associated  with  a  role  shown  in  Figure  3-2.  The 
person  sitting  at  the  terminal  may  play  several  different  roles,  but  it  is 
important  to  distinguish  between  them  when  using  the  system-  they  provide 
a  means  of  controlling  the  model,  its  implementation,  and  use. 

The  Data-Model-Definer  (DMD)  has  the  most  powerful  role:  indeed 
it  is  the  DMD  who  delegates  authority  to  all  other  roles  during  part  of  the 
data-model  specification.  The  DMD  specifies  a  data-model  by: 
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SELECT  ONE  i 

M|  DEFINE  NEW  DATA  MODEL  (0*0 
II  IMPLEMENT  AN  EXISTING  DM  (DIJ 
Dl  DEFINE  A  NEW  DATA  BASE  C 090 3 
P|  POPULATE  A  DATA  BASE  (DBP) 

Bi  RETRIEVE, UPDATE,  ETC,  (DM) 
Qt  DEFINE  A  QUERY  LANGUAGE  (QLD) 
T  t  DEFINE  TRANSFORMATIONS  (DTD) 
HI  HELP  (I.E,  PRINT  THIS  MENU.) 
xi  Exit 


Figure  3-1:  MASTER  MENU 
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•  Naming  the  concepts  for  the  data-model; 

•  Defining  the  store3~-data-definition  (in  PSN)  for  each  concept; 

•  Defining  the  occurrence-structures  (in  PSN)  for  each  concept; 

•  Defining  the  primitive-operations;  and 

0  Specifying  the  source  of  each  positional-set. 

The  meaning  of  "implementation"  in  this  opproach  is  not  the  tradi¬ 
tional  one.  The  DMD  may  specify  that  some  sets  are  defined  at  implementa¬ 
tion  time:  e.g.,  the  set  of  real  numbers  usually  depends  on  the  hardware 
architecture  of  a  specific  computer.  This,  and  any  number  of  other  sets, 
may  be  left  to  the  "implementor"  role. 

The  DBMS  implementor  (DI)  of  the  data-model  specifies  these  sets 
and  does  nothing  else.  This  approach  forces  the  DI  to  be  perfectly  faithful 
to  the  concepts  set  forth  by  the  DMD.  This  is  in  marked  contrast  to  the  way 
DBMS  have  been  implemented  in  the  past.  For  example,  in  his  original  paper, 
Codd  (reference  9),  playing  the  DMD  role,  specified  that  relations  would 
never  have  duplicate  tuples;  IBM's  System-R  group  (reference  10),  playing 
the  DI  role,  allowed  duplicate  tuples,  except  when  explicitly  removed  by  the 
user.  Such  a  co.iditicr,  coi  no.  '»ccu.  unc  •  U-  )MP  '"■arm  .rk  cau  it 
gives  the  DMD  absolute  control  over  implementation. 

Once  an  implementation  is  available,  a  data-base  may  be  defined 
under  a  new  role  (DBD),  then  populated  (DBP),  and  finally  manipulated  (DM). 
The  duties  of  the  DBD  and  DBP  roughly  correspond  to  the  duties  of  a  data 
base  administrator  (DBA).  Since  this  term  is  used  in  a  number  of  different 
contexts,  it  has  been  avoided  in  the  definition  of  the  DMP  framework. 

The  DMP  approach  also  separates  the  notion  of  a  data-model  from  the 
notion  of  a  query-language.  The  interface  between  the  two  is  the  collection 
of  primitive  operations.  The  DMD  specifies  the  primitive  operations;  the 
QLD  specifies  the  syntax  of  the  query-language  and  a  translation  of  the  syn¬ 
tax  to  the  primitive  operations.  In  section  3.3,  more  is  given  on  this. 

The  DMP  approach  should  also  provide  for  the  specification  of  map¬ 
pings  or  transformations  (through  the  DTD).  So  far,  the  mechanism  for  doing 
this  has  not  been  developed. 


3.2  Specification  of  Data  Models 


In  this  section,  we  discuss  the  specification  of  three  data  models: 
DBTG,  Relational,  and  TDMS.  Each  specification  is  currently  several  pages 
long.  Furthermore,  the  current  specifications  are  preliminary  and  (in  some 
cases)  incomplete.  However,  portions  of  each  specification  are  given  here 
to  illustrate  how  the  data-model -processor  would  manage  and  manipulate  these 
specifications. 


3.2.1  Data  Model  Underlying  Concepts 

The  concepts  of  the  (original)  DBTG  model  are: 

#  AREAS 
0  RECORDS 
0  SETS. 
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The  concepts  of  the  Relational  model  are: 

t  DOMAINS  (Explicit  and  Implicit) 

•  RELATIONS. 

Explicit  domains  are  defined  by  enumerating  the  legal  values.  Implicit  do¬ 
mains  are  defined  by  providing  a  defining  predicate. 

The  concepts  of  the  TDMS  model  are: 

•  COMPONENTS 

•  NOOES 

•  INDEXES. 


3.2.2  Stored  Data  Defini t i on s 


The  Stored-Data-Def initions  (SDD)  for  the  DBTG,  Relational,  and 
TDMS  models  are  given  in  Figures  3.2-1,  3.2-2,  and  3.2-3  respectively. 

The  TEMPLATE  command  of  DMP  allows  specification  of  the  general 
form  of  a  positional  set.  For  example,  the  specification  of  RECORD-DEF  in 
Figure  3.2-1  states  that  DECORD-DEF  is  a  (mathematical)  set  of  tuples. 

Each  tuple  has  three  position-identifiers:  RECORD-NAME,  AREA-N^ME,  and 
DATA-ITEM.  The  structures  D(I)  at  position  DATA-ITEM  are  themselves  sets 
of  tuples  as  specified  in  the  subordinate  TEMPLATE  command. 

Thus,  in  the  DBTG  model,  each  of  the  "concepts"  (areas,  records, 
and  sets)  have  stored-  ata-definitions  associated  with  them. 

In  our  definition  of  the  relational  model,  both  domains  and  rela¬ 
tions  have  stored-data-definitions  associated  with  them,  however,  actual 
values  may  appear  in  XDOM-DEF  making  it  similar  in  some  ways  to  an  occur¬ 
rence  structure. 


3.2.3  Occurrence  Structures 


Figure  3.2-4  shows  (some  of)  the  occurrence  structures  for  the 
DBTG  model.  The  currency  indicators  are  an  important  collection  because 
the  operations  (e.g.,  FIND)  depend  on  their  values. 

Figure  3.2-5  shows  the  occurrence  structures  for  the  Relational 
model.  This  consists  of  a  set  of  pairs:  relation-name  and  relation.  The 
relation  is  itself  a  structure  consisting  of  sets  of  tuples;  the  position-ids 
of  which  must  conform  to  some  restrictions  set  forth  in  the  stored-data- 
definition.  Here  we  will  not  discuss  details  needed  for  enforcing  those 
restrictions  since  they  are  likely  to  change  in  our  next  version. 

Figure  3.2-6  shows  one  occurrence  structure  for  the  TDMS  model: 
the  nodes.  As  discussed  by  Hardgrave  in  reference  11,  the  semantics  of 
TDMS  operations  are  made  iri  terms  of  manipulations  of  the  nodes  in  the  tree. 
Another  occurrence  structure  which  may  be  included  in  the  index  structure 
of  TDMS.  There  is  considerable  debate  amongst  us  over  the  inclusion  of 
index  structures  in  the  data  model  definitions.  This  is  more  controversial 
in  the  TDMS  model  than  in  others.  It  may  not,  in  fact,  be  resolved  for  some 
time. 
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Figure  3.2-2:  RELATIONAL  STORED  DATA  DEFINITION 
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Figure  3.2-5:  RELATIONAL  OCCURRENCE  STRUCTURE 
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3.3  Query  Languages 


One  important  aspect  of  this  work  is  the  development  of  a  framework 
that  encompasses  query  languages  as  well  as  data  models.  A  recent  study 
under  the  contract  (reference  11)  shows  that  one  query  language  syntax  may 
have  several  semantic  interpretations  (called  query-philosophies)  for  a  sin¬ 
gle  data  model.  The  query  language  module  of  the  Data  Model  Processor  should 
be  general  enough  to  handle  this  case.  The  work  described  here  is  still  in 
an  early  stage  of  development. 

The  query  language  module  of  the  Data  Model  Processor  requires  the 
following  material  for  each  query  language: 

•  A  GRAMMAR  TABLE,  and 

•  A  SEMANTIC  TABLE  for  each  query-philosophy. 

The  granmatical  table  (currently)  consists  of  a  collection  of  rules.  Each 
rule  has  a  rule  number,  a  match  condition,  a  rewrite  string,  and  a  semantic 
symbol.  Figure  3.3-1  shows  a  GRAMMAR  TABLE  for  the  TDMS  query  syntax. 

Metasynbols  are  enclosed  in  angle  brackets:  <,>.  These  are  simi¬ 
lar  to  metasymbols  in  BNG  grammars  except  they  have  both  syntactic  and 
semantic  parts.  The  syntactic  part  is  matched  and  rewritten  in  the  normal 
way;  however,  the  semantic  part  is  a  name  assigned  to  the  positional -set 
that  is  the  current  "mathematical  value"  of  the  expression.  As  the  syntactic 
grammar  is  parsed,  the  positional-set  is  "calculated"  in  parrallel.  This  is 
done  by  referencing  the  appropriate  semantic  table  using  the  SEMSYM  field. 
Figures  3.3-2  and  3.3-3  show  the  semantic  tables  for  the  form  TDMS  query- 
philosophies. 

DMP  also  provides  a  mechanism  for  testing  queries  after  a  data 
model  and  query  language  are  defined.  Of  course  a  test  data-base  must  have 
been  defined  and  populated  as  well.  Figures  3.3-4,  3.3-5,  and  3.3-6  show 
the  processing  of  a  query  using  this  approach.  The  query  and  sample  data 
base  are  taken  from  reference  11. 


4.0  Continuing  Work 


4.1  DMP  at  NBS 


The  Data  Model  Processor  is  currently  being  specified  and  a  proto¬ 
type  will  be  implemented  on  The  Experimental  Computer  Facility  at  the  U.S. 
National  Bureau  of  Standards.  Most  of  the  work  on  DMP  will  be  supported  by 
NBS  under  their  research  project  on  abstract  data  models. 


4.2  Mappings 

The  definition  and  processing  of  mappings  may  be  the  most  impor¬ 
tant  aspect  of  the  DMP  design.  A  good  mapping  facility  would  allow  DMP  to 
simulate  ANSI/SPARC  architecture  and  also  provide  a  foundation  for  data-base 
conversion  and  schema  transformations.  So  far,  very  little  work  has  been 
done  on  this  part  of  the  DMP  design,  though  the  effort  ultimately  requires 
this  in  order  to  be  complete. 
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4.3  Standards 


We  are  partly  interested  in  DMP  because  of  its  implications  for 
data-base  standards.  This  also  makes  it  of  interest  to  NBS,  partly 
because: 

(1)  Congress  and  0MB  expect  data-base  standards  for  DDL,  DML  and 
query  facilities  for  Federal  procurements  to  be  available  by  1985. 

(2)  The  only  data-model  that  is  seriously  being  considered  for 
standardization  is  DBTG. 

(3)  A  DBTG  standard  that  ignores  other  data  models  may  mislead 
Federal  users. 

DMP  would  provide  a  general  framework  for  standardization.  First, 
a  precise  definition  of  a  data  model  could  be  developed  and  (eventually) 
accepted  as  a  means  of  work  by  standardization  conmittees.  Moreover,  this 
would  not  preclude  the  definition  and  eventual  standardization  of  other  data 
models.  Multiple  query-languages  may  be  defined  (and  standardized)  as  re¬ 
quired.  The  mapping  facility  may  also  be  used  to  determine  definitively 
whether  two  query  languages  (or  data  models)  are  equivalent. 


4.4  Terminology 

One  of  the  most  important  results  of  DMP  development  will  be  the 
precise  definition  of  some  current  terms  from  data-base  technology.  Dif¬ 
ferent  authors  use  terms  such  as  "attribute,"  "mapping,"  "data-base,"  and 
"data-model"  with  similar  but  confusingly  different  meanings.  Newcomers 
to  the  field  are  often  perplexed  by  the  plethora  of  pseudo-defined  terms. 

The  DMP  development  requires  precise  definitions  for  many  of  these  and  other 
terms.  Thus  we  hope  to  introduce  a  new  precision  in  definition  to  this 
field. 
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